iT邦幫忙

2023 iThome 鐵人賽

DAY 26
0
自我挑戰組

GPT伴我讀一些文件系列 第 27

Day27- GPT 陪我讀 Metrics-generator Cardinality

  • 分享至 

  • xImage
  •  

基數Cardinality

基數是指給定指標序列或日誌流的標籤和標籤值的總鍵/值組合,以及它們生成的唯一組合數量。關於基數的更多資訊,可以參考「基數峰值是什麼,為什麼它們重要?」的blog文章。

雖然寫入時間序列資料庫 (TSDB) 的資料是按系列進行的,所以在收入時,高基數對性能的影響不大。但是,基數對查詢的影響很大,基數越高,需要迭代的項目就越多。

跟踪收集和指標

Tempo的伺服器端指標生成增加了通過創建基於Prometheus的指標來跟踪各種指標的功能,以增強追蹤收集的功能(例如 :

  • 總跨度呼叫計數
  • 跨度延遲直方圖
  • 總跨度大小計數

指標生成器創建了定義服務間關係的指標,這些指標使用 Prometheus 標籤(鍵 / 值對)進行查詢。

每個標籤的新值都會增加與指標相關的活躍序列的數量。這也被稱為基數的增加,而一個指標生成的活躍序列的數量與該指標存在的標籤數量以及每個標籤增加的值數量成正比。

在未修改的指標生成器實例中,自動添加了少量的標籤。因為像 span_kindstatus_code 這樣的標籤只有幾個有效值,所以每個指標生成的活躍序列數量的最大變數取決於與追蹤跨度相關的服務名稱和跨度名稱的數量。

指標生成器也可以配置為使用跨度屬性鍵 / 值對直接映射到這些標籤,從而在指標上添加額外的標籤

當配置自定義屬性時要小心:某個特定屬性中看到的值的數量越大,生成的活躍序列的數量就越多。有關活躍序列的更多資訊,請參考活躍序列文檔

假設你正在添加一個包含唯一客戶ID的自定義屬性作為指標標籤。如果你有 100 個客戶,這可能會將生成的活躍序列的數量增加多達 100 倍(例如,從 25,000 個活躍序列增加到 2.5M)。在考慮將屬性作為查詢指標的標籤時,要始終考慮它們會增加多少基數。

指標生成器的乾運行

通常,最可靠的解決方案是在乾運行模式下運行指標生成器。使用dry run模式生成指標,但不收集它們,因此不會將它們寫入指標儲存。這種情況下有一個override叫做metrics_generator_disable_collection

要估算,正常運行指標生成器並將 override 設置為true。然後,查看 tempo_metrics_generator_registry_active_series,以獲得該設置的活躍序列的估計。

基數 (Cardinality) 總結:

  1. 定義:基數是指給定指標序列或日誌流的標籤和標籤值的總鍵 / 值組合,以及它們生成的唯一組合數量。
  2. 性能影響:
    • 收入時:由於時間序列資料庫 (TSDB) 的資料是按序列收入的,高基數在收入時對性能的影響不大。
    • 查詢時:基數對查詢的影響很大。當基數較高時,需要迭代的項目數量就越多,這可能導致查詢速度變慢。
  3. Tempo 和指標:Tempo 的指標生成工具可以增追蹤收集的功能,這包括生成基於 Prometheus 的指標來跟踪如跨度呼叫計數、延遲和大小等指標。
  4. 標籤和基數:每個新的標籤值都會增加與該指標相關的活躍序列的數量。換句話說,基數的增加與該指標存在的標籤數量和每個標籤的值數量直接成正比。
  5. 增加基數的考慮因素:當考慮增加自定義屬性(如獨特的客戶ID)為指標標籤時,應特別小心,因為這可能會大大增加基數。增加的基數可能會對查詢性能產生影響。
  6. 測試和估算:建議在實際應用前進行乾運行,以評估標籤和其潛在值如何影響基數。

總之,當處理指標和日誌時,理解基數及其對性能的潛在影響非常重要。特別是在配置或調整時間序列資料庫或日誌系統時,應該總是考慮到基數的影響。


上一篇
Day26- GPT 陪我讀 Metrics-generator Active series
下一篇
Day28- GPT 陪我讀 Metrics-generator Span metrics
系列文
GPT伴我讀一些文件31
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言